This invention relates to processing of electronic forms (eForms) and particularly to creating eForms with business logic.
Forms are widely used in business, industry and government. Forms can be stored in various formats and usually can be printed on paper. However, with the development of electronic business practices, eForms have become popular. Consequently, there is an increasing demand for creating eForms by generating new eForms from the start and by revising existing eForms which may or may not conform to the same format as the desired eForm.
The smallest unit in an eForm is called an “Item”, such as Label, Line, Field, Checkbox, Radio button, Date Picker, Pop List and so on. Attribute information on items, such as types, geometrical attributes (size and location etc.) and contents and/or logical attributes of items, are stored in an eForm file. Two of the most important characteristics of an item are visibility (whether an item can be electronically visualized to a user) and fillability (whether an item can be electronically filled in by a user). If an item can be filled in electronically by a user, it is called an interactive item. Otherwise, it is called an non-interactive item.
All eForms can be categorized into three types according to their interactive functionalities:                (1) Non-interactive eForms have no interactive items. They look like their source paper forms. Users can read them on a display but can not fill them in electronically on a machine.        (2) Basic-interactive eForms have the minimum interactive items that eForms could have, e.g., fields.        (3) Advanced-interactive eForms have various interactive items. In addition to basic interactive items contain advanced interactive items. More importantly, advanced-interactive forms can recognize and apply business logic, as discussed below.        
A file containing eForms is called an eForm file. Currently, eForm files exist in many formats, such as PDF, RTF, TEXT, HTML and so on. These formats may be incompatible with each other. When an eForm is converted from a source format to an target format, developers usually rely on an automatic tool, and then manually modify the converted eForm to satisfy clients' requirements.
Basic tools are available that convert an eForm into a target format that generates a displayed form apparently identical to the original form. However, the conversion process eliminates all of the interactive features that existed in the source documents.
Other tools available for converting existing eForms to new formats retain at least some basic interactive properties in the new eForms. The eForms created using such tools do not necessarily retain all of the interactive properties of the original eForms. When eForms are converted in batch, it takes considerable time for developers to manually recognize and convert the form items not appropriately converted by the conversion tool.
Additionally, eForms may integrate considerable business logic, such as verification for input of items, mathematical calculation and logic computation between items; and business flow relationship including mutual exclusion, joint operation and jump between items. Business logic information on eForms can be used in real-time processing of users' input, standardizing users' input and guiding users to fill in the forms more efficiently and correctly. In practice, business logic on eForms may be defined by programming, for example, in HTML language.
Before now, there has been no tool available for automatically recognizing business logic in source eForms during conversion of eForms. Existing conversion tools sometimes prevented business logic from being integrated into a converted form or corrupted the business logic integrated into the converted form. Manually reestablishing business logic in converted eForms is both inefficient and prone to the introduction of errors.
While the discussed problems are often worse when converting an eForm from one format to another, similar problems can also occur when generating a new eForm from a source eForm having the same format. In such a case there is still a need to recognize business logic in the source eForm and generate the new eForm with unimpaired business logic.